The recent growth and acceptance of the Internet and the World Wide Web has focussed much attention to networked systems in general and to the potential for mass communication and information transfer. More and more groups of individuals can now satisfy a long felt need for rapid and wide area distribution of information including documents containing thousands and thousand of pages. Now, over networks, such massive amounts of information can be sent from one terminal or server to another terminal or server in a network almost instantaneously.
With the availability and ease of use of such a resource, more information is being transferred on a routine basis. Many times a message is sent via an electronic mail and documents are referenced in the message and are routinely attached and sent with the message. Frequently, the attachments are voluminous and often contain rich graphic detail. In many cases, the intended receiver or consumer of the information already has, or does not need, the attachment and the attachment is quickly deleted after receipt. For example, a stock movement report may be sent from a "supplier" to a "consumer" and the report may include a statement or notice of a watched-for stock-related event along with a "10K" report or company annual report. The consumer may already have the "10K" report and the annual report, in which case, the attachments will be deleted but only after they have been sent to the consumer. Thus massive amounts of bytes of information may be being transferred even with the simplest of messages. As the ease of information transfer increases, so does the need for, and the amount of, information being transferred. On a large scale, there is a tendency to overload communication channels with unnecessary information, which in turn, may slow down the entire network.
In so called "service applications", which run on system or network servers, "suppliers" of information send information to the server memory and such information is held in memory until a "consumer" of information at another terminal in the system, asks for or "pulls" the posted information from the service application to the consumer's terminal. In some service applications such as so called "Event/Notification" service applications, a "pull" consumer has to specifically apply the "pull" operation to the event/notification channel in order to get the event. For example, a stock market "watch" service application may be tasked to "notify" a consumer when a designated stock reaches a certain value or changes by a certain amount. A pull consumer will, however, not be aware of this event unless the pull consumer logs on to the application and specifically directs that all messages that may be at the server site and addressed to the consumer be delivered. Similar "event notification" applications exist for manufacturing operations where an assembly line terminal needs to be informed when a part is available, or for the insurance industry where an agent needs to be informed when the status of a customer has changed.
The "pull" procedure is also required in standard electronic mail systems where a consumer or user, after logging on to a server, must specifically ask to have any waiting mail to be sent to the consumers terminal. This is not done automatically and if the user logs on to the server and does not request to have his mail sent, the mail will not be sent and the consumer may not even be aware that he has mail. Once the consumer requests that the mail be sent, the electronic messages or mail, including any and all attachments, are sent to the consumer terminal. The user therefore cannot determine whether the attachments are needed until they have already been sent to the consumer's memory.
In most of the above examples, if for any reason, the pull consumer fails to pull the event from the service application, the events will be accumulated inside the event/notification channel and will be discarded after a period of time. The pull consumers need to be immediately informed that there are messages waiting to be pulled. Also, events with the same priority will be pulled in a first-in first-out order. The pull consumer has no option to pull a particular event out of the order in which the events are stored in the message queue.
Thus there is a need for an improved methodology and implementing system which enables a more efficient and more effective use of communication and information transfer systems, especially in event notification systems which include pull-type communication techniques.